1. Technical Field
The present invention relates to network security, and more particularly, to security planning with hard security constraints.
2. Discussion of the Related Art
A component environment is an environment where entities (e.g., data, documents, machine parts or raw materials) are processed by a network or multiple networks of interconnected components (e.g., computers, business services, factory machinery, etc.). Each component can consume and produce entities. The components can be connected by delivery channels. If two components are connected, all or some of the entities produced by one or both of the components can be consumed by the other component.
The components can also consume entities taken from external (e.g., primal) sources if a corresponding source-component connection is established and the entities produced can be shipped outside the system. The entities shipped outside the system are considered a final product of the component network. The component environment provides the infrastructure necessary for connecting components, activating the components and delivery channels, and implementing the entire production cycle, delivering entities from sources, to components, and to consumers of the final product.
The main advantage of a component environment is component reuse. For example, different networks of components can be composed as needed to generate a final product according to current business requirements. The same component can participate in multiple networks. In some environments, for example, in computer systems processing data in digital formats, entities can be easily copied, which further increases potential reuse, thereby allowing the entities to be produced once but consumed multiple times by multiple processing components.
In many environments, components can be rearranged dynamically to form new networks to adapt to changing conditions, such as changing availability of primal sources or introduction of new (e.g., more efficient) components. Examples of component environments include computer systems such as semantic grid, stream processing, web services and autonomic computing systems, as well as automated production lines and business document flows.
In many applications, entities flowing in and out of a component network and between components are considered valuable entities and the value contained in the system must be protected. Value of an entity can be, for example:
1) Actual monetary value of a physical object (e.g., an entity), or replacement value of the entity, if the entity is a physical object.
2) An estimate of the loss resulting from making information public or releasing it to another party, if, for example, the entity is a private document, or an object containing secrets (e.g., trade secrets or personally identifiable information protected under privacy laws).
3) A combination of 1) and 2) when the entity has both monetary value and trade secret aspects, e.g., if secrets can be discovered by inspecting or reverse-engineering the entity.
Special security procedures are followed in such environments to prevent potential loss of entities. Without loss of generality, it can be assumed that the delivery channels between the components are trusted and secure since many well known techniques exist for creating secure delivery channels. For example, when the entities consist of data, cryptographic techniques can be applied to protect data in transit from being disclosed or modified.
As described above, losses can occur at the components if the components leak the entities or at the consumer side if the consumers of the product leak the entities. A method for controlling security risks in these environments is to restrict the set of entities exposed to components and product consumers to the minimum necessary required for system functionality. This can be achieved with the enforcement of access control policies, which are also known as hard security constraints. The term hard security constraints is used because the access control policies are strictly enforced, and violation of these policies leads to a security risk that cannot be easily quantified. In other words, the system satisfies the hard security constraints, or it does not.
To prevent losses, various security policies for access control are used. The most commonly used policies belong to one of two types: Mandatory Access Control (MAC) and Discretionary Access Control (DAC). In DAC policies, the principals owning the entities are allowed to grant and revoke access to other principals. In MAC policies, entities do not have owners, and access to entities is controlled by the environment based on categorization of the entities and clearance levels assigned to the principals. Both classes of access control policies specify a set of formal rules that are used by an enforcement or auditing facility to decide whether a subject can access an object, and take appropriate action (e.g., deny access or raise an alarm).
In component environments, the entities play the role of objects, and components play the role of subjects. Access control policies are implemented by assigning labels to objects and subjects, and specifying the access rules in terms of the labels. In particular, implementation of an access control policy may require that object labels are assigned to entities, and subject labels are assigned to components. Further, the policy compliance of a network of components can be verified using access control rules defined by the policy.
The literature in the field of access control commonly discusses permissions for subjects to “read” and “write” objects, which in the context of component environments corresponds to components consuming and producing entities. The “write” operation is understood as creating a new object (e.g., an entity), and not as modifying an existing object (e.g., the entity). In particular, the subject label of each component producing entity has “write” access to the object label of the produced entity, and the subject label of each component consuming an entity has “read” access to the object label of the consumed entity.
In many access control systems the set of subject labels is partially ordered. For example, for any subject label there can be a number of other subject labels that have “read” access to the same or a smaller set of object labels, which at the same time, have “write” access to the same or a larger set of object labels. In other words, the subject label assigned to a component can potentially be “reduced” in this partial order such that the subject label still allows “read” access to object labels of all consumed entities and “write” access to object labels of all produced entities and at the same time restrict “read” access to a smaller set of entities.